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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 
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GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3 GPP and ETSI identities can be found under 
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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

Ready for Converged Management 

This specification is part of a set that has been developed for converged management solutions. 
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Scope 



On-going industry convergence and pressure to reduce cost is placing an ever-increasing emphasis on the need to 
rationaUze and ahgn various network management aspects across boundaries of standards/specifications producing 
organizations. The cost, resulting from integration and management challenges, of the lack of a coherent treatment of 
the whole network has becoming increasingly apparent to the point where operators of networks are demanding action. 

This document provides key concepts and principles for the Federated Network Information Model covering all key 
aspects of a solution to the on-going industry convergence challenge. The proposal focuses on Information Model 
federation and is constructed to best deal with the various contradictory pressures of the current environment providing 
a pragmatic and realizable approach. The structure proposed will be called the Federated Network Information Model 

(FNIM). 

The proposal set out in this document: 
Explains: 

- How, from a technical perspective, a number of standards and specifications generated by different 
organizations can function together to bring greater coherence to the management of converged networks and 
hence reduce operations costs. 

- Specifically how TM Forum and 3 GPP can work with each other and with other industry groups in a 
Standards Federation to develop a Federated Network Information Model drawing on insights from the broad 
community (including the TM Forum SID [7], TM Forum MTNM/MTOSI [8], 3GPP SA5 IRPs [14], DMTF 
CIM [15]). 

- How the Federated Network Information Model can be used from a technical perspective (with the focus here 
being the Network Model). 

Recognizes: 

- The network is "always on", therefore changes in management solutions should not impact networks in 
operation. 

- There will always be on-going change. 

- That this is only a start on a very long journey. 
Allows and enables: 

- Decoupling of concerns across the industry whilst growing industry coherence. 

- Differing delivery pace across the industry whilst aiming for industry convergence. 

- Variety from innovation whilst removing unnecessary variety in management infrastructure. 

- Temporary divergences and overlaps during the convergence process. 
Ensures: 

- Change is made only as a result of understanding of specific market needs. 

- Progress by providing coherent solutions to satisfy the needs of all participating industry partners in order not 
to be blocked by the slowest laggard. 

Highlights: 

- The challenges of dealing with differing methodologies/tooling used across the standards arena and points 
out that methodology/tooling differences if ignored will significantly slow progress towards the target. 

- The need for development of a new governance regime and points to some of the attributes of such a regime. 

- An approach of gradual restructuring and a controlled converging coherence starting small and growing step 
by value-justified step. 
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- The challenge of presenting the models so all can have an identical understanding. 

- The challenge of interpreting models from different origins, with their different terminology and viewpoints, 
to arrive at a shared understanding through a federated model. This leads to recognition of the need for a deeper 
uniform semantic analysis of the area covered by the umbrella information model (UIM) and the navigation 
points among concrete models which may further lead to the need for the development of information 
architectures and patterns. 

This document focuses on the Information Model aspect of the problem as it is clear that the lack of an agreed-upon, 
coherent information model across organizational boundaries to support the FMC aspects of the industry that defines 
the things to be managed and the way they should be expressed is one of the first aspects that need to be tackled. 

Editor's note: Prior to embarking on a further summary of the proposal and its benefits, it is important to emphasize 
that the definition of the term "model" has to be carefully considered. A model is comprised of parts that 
themselves can be seen as models. As a consequence whether this activity results in a single model or a 
set of models depends upon perspective. The critical consideration is whether the parts of the solution can 
be interrelated and from the perspective of the problem highlighted above whether the parts can be 
interrelated across what were previously un-navigable barriers. The solution offers this navigability. 
Conversely it is critical that the solution offers appropriate decoupling of concerns and of governance. 
Whether this is considered one model or many is not relevant as long as the solution offers the properties, 
such as those noted above, that are critical for industry success. 

This document proposes a Federated approach to model development and emphasizes the need for the development of 
an Umbrella Information Model (UIM) and its relationships with the other domain specific models. The document also 
deals with direct relationships between domain/technology specific concrete models. 

It is proposed that: 

- The work will be published and expressed in UML and will also be published in formats appropriate for each 
of the participating bodies to absorb (this may require nothing more than the UML format in some cases). The 
output form required by a particular body will be generated by resources contributed by that body. 

- As necessary the model will be embellished using stereotype to express all aspects/properties of the model. 

The proposal recognizes that the TM Forum Information Framework (SID) [7] and the TM Forum Integration 
Framework (MTNM/MTOSI) [8] work provide an enterprise-wide structure and model that can be used to seed the 
converged model. The proposal recognizes that the 3GPP SA5 group work [14] provides models relating to mobile 
networks (including RANs, CNs and IMS) that can be used to seed the converged model. 

The proposal: 

- Ensures on-going reduction in cost of integration and improvement of degree of integration for the purpose of 
End-to-End management; 

- Enables models from many organizations to be used together for the purpose of End-to-End management 
(recognizing that there are a number of critical governance issues to be overcome to enable this); 

- Provides structure for the alignment on a deeper understanding of the semantics and for the development and 
maintenance of an information architecture and associated patterns; 

- Provides both an initial pragmatic solution form and a longer term target; 

- Recognizes that the model will evolve in stages, but will never be "completed" and hence this is an on-going 
activity; 

- Recognizes the importance of providing solutions that are backward compatible to existing standards. 
See [13, 17] 
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This content of this document has been jointly developed by 3 GPP and TM Forum as part of the Joint Working Group 
on Resource Model Alignment [18]. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

- References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

- For a specific reference, subsequent revisions do not apply. 

- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] ITU-T X.680 "OSI networking and system aspects - Abstract Syntax Notation One (ASN.l)". 

[2] 3GPP TS 32.642 "UTRAN network resources IRP: NRM" . 

[3] ATM Forum, Technical Committee, Network Management, M4 Network View CMIP MIB 

Specification ("CMIP Specification for the M4 Interface", Sep 1995, http ://ww w.broadband- 
forum.org/ftp/pub/approved-specs/af-nm-QQ27.QQQ.pdf) . 

[4] 3GPP TS 32.622 "Generic network resources IRP: NRM". 

[5] MEF Technical Specification MEF 7.1, "Phase 2 EMS-NMS Information Model", October 2QQ9. 

[6] 3GPP2 S.SQQ28-E "OAM&P for cdma2QQQ (Overview, 3GPP R7 Delta Specification, 3GPP2 

Network Resource Model IRP)". 

[7] TM Forum GB922, Information Framework (SID) Suite, Release 9.Q 

(http://www.tmforum.org/browse. aspx?catID=9285&artf=artf2Q48). 

[8] TM Forum MTOSI 2.Q 

( http://www.tmforum.org/MTOSIRelease2Q/MTOSISolutionSuite/35252/article.html) . 

[9] TM Forum SDl-44_ConnectionlessTechnologyManagement.pdf available as part of [8] 

(Especially Appendix III "Mapping MEF - MTNMETH"). 

[IQ] TM Forum SDl-7_DSL0verview.pdf available as part of [8]. 

[II] TM Forum SDl-18_layers.pdf available as part of [8] (Especially 4.2.7 ATM and SDH capable 
STM-4). 

[12] TM Forum "Connectionless, Connection Oriented Convergence and TP Modelling" 

(http://tmforum.org/FeatureDescription/ConnectionlessConnection/41718/article.html). 

[13] TM Forum TR 146 "Lifecycle Compatibility Release l.Q" 

( http://www.tmforum.org/TechnicalReports/TR146LifecycleCompatibility/36664/article.html) . 

[14] See Appendix B for the list of 3GPP Technical Specification series on Network Resource Models. 

[15] DMTF CIM ("Distributed Management Task Force Common Information Model"). 

[16] 3GPP TR 32.852 "Fixed Mobile Convergence (EMC) 3GPP/TM Forum Model Relationships & 

Use Cases". 

[17] 3GPP TS 32.154 "Backward and Forward Compatibility (BEC); Concept and definitions". 

[18] 3GPP / TM Forum JWG RMA: "EMC Federated Network Information Model (FNIM)" V3.Q. 

[19] 3GPP TR 21.9Q5: "Vocabulary for 3GPP Specifications". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [19] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [19]. 

Encoding: It is the process by which information is converted into symbols to be communicated. In this document, the 
'information' is captured by the so-called model. 

Operations/Notifications: Specification conveyed over an interface between two interacting parties indicating the 
action to be performed on some identified entity or set of entities. In general the "operations model' '/"business services 
model"/"action model" (or similar) cover the definitions of the actions performed to change the state/value/etc. of the 
thing and to receive information on changes that have occurred to the thing and to receive information on changes that 
have occurred to the thing. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [19] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [19]. 

DN Distinguished Name 

FIM Federated Information Model 

FNIM Federated Network Information Model 

FMC Fixed Mobile Convergent 

IM Information Model 

LT Layer Termination 

NM Network Management 

UIM Umbrella Information Model 
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Characteristics and context of FNIIVI 



4.1 



Characteristics 



The FNIM is "large scale" in the following sense: 

- Different authorities (SDOs or standard organizations including expert group) are responsible for the 
development, maintenance and evolution of their own domain specific models. 

- Operators may use the whole or part of the FNIM depending on their own business cases. 

- Vendors can supply products using part of the FNIM depending on their own business cases. 

- The FNIM needs to hold thousands of inter-related modelled entities. Different versions of modelled entities can 
co-exist in FNIM. 

4.2 Contexts of FNIM 

4.2.1 A broad standardization context 




Figure 1 : Broad standardization context 

The figure depicts a broad standardization context. The concept embodied by the term Information Model (of Managed 
Elements etc.), abbreviated as IM, is separable from the concept of Process and Operation Model (covering definitions 
of activities). Clearly the Process and Operation Model influences and is influenced by the IM. 

Encoding in general (of information defined in IM Process and operation model) to achieve an Interface 
Implementation is also separable and is not considered further here. Each aspect of the problem is guided and 
constrained by an appropriate Architecture (e.g. Metamodel) that defines the breadth and scope of the aspect. 
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The things in the IM are relevant to some activity identified in the Process and Operation Model. That relevance is 
necessary in order to fulfil some purpose of the system. The things in the IM are in many cases relevant to expose at 
some Interface in which case they will dictate some aspects of structure of information defined in IM and Process and 
Operation Model. 

The IM can be broken down into two parts: 

- Broad conceptual model that articulates the concepts of the problem space (alternative names are purpose 

neutral, implementation neutral views) 

- Specific purpose models that each articulate the solution to a specific problem (alternative names are purpose 

specific, implementation neutral views) 

In summary, the following definitions apply to terms of the above figure: 

- Information Model (IM): The representation of things, their properties and their relationships. Example: 

TopologicalLink and TerminationPointEncapsulation are things that are interrelated and have properties 
represented via attributes. 

- Process and Operation Model: The representation of the relevant activities required to facilitate the running of 

the business including the flows and interactions. Example: "IsolateCustomerProblem" and 
"Track&ManageCustomerProblem" are relevant activities that are interrelated by flows of control and 
information. "getAlarmList", "getAttribute" and "createFlowDomainFragment" are examples of operations. 

- Solution Component Structure: The representation of the units of functionality assembled to support the 

information defined in the IM and in the Process and Operations Model. Example: NMS and EMS are solution 
components that support various process activities and maintain information. The two are interconnected as part 
of the structure of the management solution. 

- Interface specification: The definition of the interactions between the solution components supporting the 

exchange of information and control associated with running of the business. This interaction is in terms of the 
information defined in the IM and in the Process and Operations Model. 

- Interface implementation: The implementation form of the interfaces appropriate for the runtime environment. 

- Architecture: The patterns, rules, metamodels and structures derived from the fundamental properties of the 

problem space that guide and constrain the development of the model of each aspect of the problem space. 

4.2.2 Integration with 3GPP/SA5 standard production processes 

This context describes how 3GPP/SA5 would use the FNIM to produce its specifications that would be used for EMC 
network management purpose. 

This context only refers to the model part. Note that the ENIM is not related to the design of any network management 
protocol. 

The ENIM has multiple components. Two such components are the Umbrella Information Model (UIM) and a number 
of concrete models (see definition of ENIM in section 0). The right-most box of the following diagram depicts the 
classes of the UIM. The middle box depicts one of the concrete models, i.e. the 3GPP IRP NRM concrete model. The 
concrete classes are designed as extension of UIM and must use the appropriate relations defined (see clause 6.1). 

Using the concrete classes (of the concrete model) as input, 3GPP/SA5 uses appropriate tools to generate and publish 
the various specifications. 
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Umbrella classes 



Imports/uses 



3GPP IRP NRM 

Information Service 

concrete classes 



Produced by appropriate^ 
tools 



3GPP IRP NRM 
Solution Set 
specifications 



Figure 2: Context of 3GPP/SA5 usage of FNIM 

4.2.3 Integration with TM Forum's universe of discourse 

This context describes how TM Forum would use the FNIM for FMC network management purpose. 



Information Model (IM) 




Figure 3: Context of TM Forum usage of various Models 

The Federated Information Model (FIM) is a subset of the IM. It relies on a coherent Information Architecture 
(including meta-model to ensure integrity and coherence). The FIM focuses on IM relevant to the generation of 
interface specifications but does not cover the specific encoding. The positioning of interfaces is essentially dictated by 
the Solution Component Structure that defines boundaries. 

The following definitions apply to the figure: 

- Information Model: See definition in section 4.2.1 "A broad standardization context". 

- Federated Information Model (FIM): The parts of the IM that are being developed collaboratively or have been 

developed collaboratively and agreed by two or more standards bodies. Some of these parts will be found in the 
specific SDO or standard organization including expert group models. 

- Federated Network Information Model (FNIM): The part of the FNIM that deals with Network domain 

considerations. There will be other domain models in future (F*IM). 
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- Umbrella Information Model (UIM): The parts of the FNIM that represent the agreed model structures that 

various SDOs or standard organizations including expert groups will use (via "specific linkages" including 
inheritance, mappings and other derivations ^^^^ ^) for their definitions of their respective Domain/Technology- 
specific concrete classes. The use of UIM maximizes the probability of the Domain/Technology- specific 
concrete classes being semantically consistent, a necessary characteristic for FMC NM purposes. 

- 3 GPP IM, TM Forum IM: The IM of all things relevant to the specific SDO or standard organization including 

expert group including elements that are federated and elements that are not. The federated elements are related 
to and/or derived from the UIM in the area of the FNIM. 

Note 1 : The phrase "specific linkages" means "inheritance, mappings and other derivations" and is used in other 
parts of this document. 
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Features of FN I M 



5.1 Introduction 



This section describes FNIM features that are essential for the maintenance of the integrity of a large and scalable FMC 
network model. 



5.2 Model components 



The FMC network model is partitioned into model components. Clear rules are defined for inter-relationship of model 
components. The rules should be simple and stable (not changing frequently). 

Use of model components and adherence of the simple model component inter-relationship has the following 
advantages. 

- It removes the need to keep the evolution of various model components in synchrony (see more on 5.6). For 

example, it is a valid implementation where one model component has evolved (requiring new solution) while 
other model component remained unchanged (does not require new solution). 

- Domain experts (e.g. radio experts) can focus their design on their model components and (can, if they want to) 

be ignorant of contents of other model components (e.g., mobile backhaul networks experts). 

5.3 UIM Model component partition 

The UIM model component is further partitioned. The partitioning of the UIM model component supports the 
following: 

- A body (e.g. SDO or standard organization including expert group) adoption/use of UIM specification 

releases/versions need not be lockstep with the availability of the UIM specification releases/versions. 

- A body adopting/using a UIM specification may or may not use a particular UIM partition, as long as the 

partition in question is not classified as essential or mandatory for adoption/usage. 

- A vendor's implementation needs not have lockstep with UIM specification releases/versions. 

- A vendor may or may not implement a specified UIM partition, as long as the partition in question is not 

classified as essential or mandatory by the body that governs solutions in that part of the problem space. 

- A solution, an assembly of capabilities specified by UIM partitions of the UIM model components and other 

model components, must be such that mixed versions of UIM partitions and their asynchronous upgrades are 
achievable (Lifecycle Compatibility [13]). 

5.4 Ability to navigate among instances of different model 
components 

This ability allows an instance (source instance) of a class defined in one model component (source model component) 
to relate (navigate) to another instance (target instance) whose class is defined in another model component (called 
target model component). 

Two mechanisms are recommended. 

- The source model component uses a class called ExternallOC. An instance of this ExternallOC is a 

representation of the target instance (which in turn, is the representation of a function under management). In 
the source model component, the source instance is related (can navigate) to this ExternallOC instance. 
ExternallOC instance captures some information of the target instance such as the DN of the target instance. 
How this information is kept in synchrony with that of the target instance is case dependent. 
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- The source instance is related (enables navigation) to the target instance, i.e. the source instance would capture 
the unique name by which the target instance is known, such as the DN of the target instance. How this 
information is kept in synchrony with that of the target instance is case dependent. 

The source and target instances may be managed by different Domain Managers. 

This source and target model components may be defined by different SDOs or standard organizations including expert 
groups. 

Note that the use of these two mechanisms is well known. 

5.5 Ability to import model elements designed elsewhere 

Use of this feature is for model component-A to include model elements (e.g. classes) defined in another model 
component, say model component-B. 

This feature can also be used, say by a 3 GPP specified model component-A, to include model elements (e.g. classes for 
transport managed resources, TM Forum defined classes) defined in another model component, say component-B, 
specified by other organizations (e.g. TM Forum, BBF, etc.) 

This feature is essentially a copy and paste procedure with a clear indication of the 'source' or design authority of the 
imported model elements. 

Note that the concept of Import is well known in software and modelling design work. 

5.6 Independence of tool and platform 

Use of FNIM does not require nor mandate the use of a specific tool. Tool and model are evolving at their own paces 
and decoupling them allows standard authors to choose the best tool for the job (e.g., validation model design, 
generation of solution). 

Decoupling model design from specific platform (e.g. development platform, testing platform) is a necessary condition 
since it is unrealistic to assume a particular platform for all products in compliance to FMC NM standards. 

5.7 Independence of solution technology and access protocol 
design 

This does not imply nor mandate the use of a specific machine-readable language, e.g. XSD, CORB A IDL, GDMO, etc, 
to express the designed model elements. 

This does not imply nor mandate the use of a specific access protocol (e.g. to manipulate or query the parameter values 
of a class instance). It ensures no dependency can exist between model design and access protocol design. 



5.8 Experience 



The FNIM concept has been used successfully, albeit in a much smaller scale than FMC network model, in the 
following cases. 

- 3GPP2 develop/maintain/evolve the model component(s) related to CDMA2000 technologies, while 3GPP does 

similar work related to GSM/UTRAN/EUTRAN technologies plus the GENERIC NRM IRP model component. 
Vendors can implement standard network management solutions for these technologies and operators' 
IRPManagers (a 3 GPP IRP Framework conceptual object) can use these solutions in a unified way. 

- BBF/Home develop/maintain/evolve the H(e)NB network resource models. Relevant IRP Framework model 

components makes references to those H(e)NB network resource models allowing, for example, an 
IRPManager to download configuration files to, upload PM counters from and receive alarm notifications from 
H(e)NBs. Vendors can implement standard network management solutions for these technologies and 
operators' IRPManagers can use these solutions in a unified way. 
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5.9 Model components release handling 

Each SDO or standard organization including expert group has its own well understood and maintained specifications 
release mechanism. Each release will have some definition of features that need to be covered and some timeframe for 
that coverage. There is clearly a time gap between the completion of a new feature and its availability of the 
management solution for that new feature. Some vendor/operator organizations may choose to intercept developing 
work (early adopters) whilst others may chose to wait until the solution is complete and has been field proven for 
several releases (laggards). It is critical that the mechanisms and structures put in place to enable the development and 
use of a converged model do not disrupt any standards body's ability to deliver to its committed schedule. 

Having said that, it is also clear that to move to a more coherent standardization environment that supports the 
converged network, rather than siloed and inefficiently managed network fragments, will require investment and will 
require changes in approach by all concerned. 

Recognizing that a change of approach will only be applied where there is a suitable business driver, it is expected that 
the industry business case will be needed to justify any specific deployment impacts to ease the perception of cost 
(see [16] for examples of industry business cases). 
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6 Elements of the FNIM 

6.1 FNIM components 

This section describes the two key elements of FNIM (UIM and Domain/Technology- specific Concrete Models) in 
terms of model component relations (6.1/6.2) and production of model definitions specifications (6.3). 

The Umbrella Information Model (UIM) provides abstract definitions applicable across Domain/Technology- specific 
Concrete Models to enable end-to-end consistency of such definitions (it is described as 'abstract' in the sense that its 
components are used via "special linkages" by Domain/Technology-specific Concrete Models, and that it is not 
designed for the purpose of partial or full instantiation of its components and is not sufficient to provide meaningful 
network management service). 

Domain/Technology-specific Concrete Models are described as 'concrete models' in the sense that their instantiation is 
necessary to provide meaningful management services. These Domain/Technology-specific Concrete Models uses 
"special linkages" with the common definitions of the Umbrella Information Model (UIM) for the purpose of end-to- 
end consistency of management information semantics. In addition, these Domain/Technology-specific Concrete 
Models have specified relationships between each other to enable end-to-end monitoring and management of a 
converged network. 

6.2 Relations between model components (including UIM) 

This section is a graphical representation of the FNIM in terms of relation between model components. 
There are two areas considered: 

- The definitions of the classes inside the UIM model component. 

- The definitions of relation (RO in Figure 4) used between various classes in UIM model component and other 

model components. 

The aim is to have identical RO for use between the UIM model component and other model components while the UIM 
model component need to have no knowledge of its usage by classes of other model components. This will ensure 
consistency (e.g. resource management style, paradigm) for managing mobile managed resources, as well as other 
managed resources such as transport managed resources. 



Umbrella Information 
Model (UIM) 




RO : Import / reference 



.--^^'^V^'' § ^^V**^^©., 




3GPP2 





NW & device \ ^ ' '^^' '"^®""® \ 3GPP wireless 
V\^reless NM ^^^^^^^^ ^^^^^ NW concrete model nw concrete model 

concrete model 



ME F MET concrete 
model 



Figure 4: Relation between UIM model component and other model components 

Taking the example of "3GPP wireless network classes" and the UIM, 3GPP model components (e.g. TS 32.622 [4]) 
would import relevant UIM classes and make derivatives for their use. RO in this case is an inheritance relation. There 
are other forms of relations that could be defined. 
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6.3 Relations among pairs of model components 

This section is a graphical representation of the FNIM in terms of bilateral relation between each pair of model 
component, neither of which is a UIM model component. 

The relation between pairs of model components may not be same. Each relation may or may not be symmetrical. 
UIM may not be involved in such pair- wise relations. 




.R1.-- 



3GPP wireless 
NW concrete model 
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NW concrete model 
[7] 



BBFATMNWand 
device concrete 
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3GPP wireless 
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MEF 7 EMS-NMS 
Information Model 
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. -R5. - - 



MTOSI wireline 
NW concrete model 
[7] 




MEF 7 EMS-NMS 
Information Model 
[5] 



Figure 5: Relation between pairs of model components (not involving UIM model component) 

Taking the example of a relation between 3GPP model components and BBF ATM model components (i.e. R3): the 
3GPP model components would create necessary 3GPP defined ExternallOC representing one of the classes of "BBF 
ATM network and device classes". This type of relation is used extensively in the 3GPP IRP framework for the 
purpose of navigation from one managed domain to another. 

In the case of the relationship between MTOSI and MEF there is an association where MEF does not provide a concrete 
model but instead a detailed abstract model. The MTOSI concrete model is mapped to the MEF 7 model (see [9]). 



6.4 



Production of solutions re FNIIVI 



This section is a graphical representation of the FNIM in relation to tools that generate machine-readable model forms 
in various languages such as XSD, CORB A IDL, GDMO, etc. 

In the context of this document, The "Solution specifications" refers to only the model part and not the 
Operations/Notifications part (e.g. encoding of the managed resource modelled constructs over the wire). Examples of 
such are the various 3 GPP NRM IRP SSs. They do not refer to the Interface specifications such as the 3 GPP Interface 
IRP SSs. This document does not deal with the question if the Tool generates the Interface specifications. No single 
physical Repository is required to hold FNIM. 
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Figure 6: (Model) Solution production related to FNIM 
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7 Name Convention for class instances (managed 

objects) 

Editor's Note: This section describes a method to make DN unique. There is greater complexity of name space 
management to explore as a result of current practices of manual administration of name spaces. For example an 
Operator has his way (or system of identification) to identify a thing that has a DN, as well. 

7.1 Background 

FMC NM involves a federation of models, which are designed and maintained by different SDOs or standard 
organizations including expert groups. The model(s) contain classes of managed resources. Instances of these classes 
are identified by an identifier (called name in this document). 

To maintain integrity of the class instances of the federated model, the names of all instances, whose classes are defined 
under the federated model, must be unambiguous, i.e. an (unambiguous) name can only refer to one instance and an 
instance may have more than one (unambiguous) name. 

For simplicity, FMC NM employs unique names, i.e. one name can only refer to one instance and one instance have at 
most one name. 

7.1.1 Name 

A name is a unique identification of an FMC FNIM specified managed resource instance. 

7.1.2 Name space 

A name space (NS) is a collection of names. This name convention uses a hierarchical containment structure, including 
its simplest form - the one-level, flat NS (the rightmost NS of Figure 7). This name convention does not support an 
arbitrarily connected NS, or graph structure, in which a named managed resource can be both child and parent of 
another named managed resource. 

The Figure below shows some examples of supported NSs. 



Name space 

Name space 



Name space 




• • • • 



Figure 7: Examples of supported name spaces 
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7.1.3 Unique names 



Names in a NS can be organised as one or more inverted tree hierarchies (see the left-most two NSs of Figure 7). A 
managed resource instance that contains another one is referred to as the superior (parent), whereas the contained 
managed resource instance is referred to as the subordinate (child). 

FMC NM involves a federation of models, which are designed and maintained by different SDOs or standard 
organizations including expert groups technology-domain-specific-models. The model(s) contain classes of managed 
resources. Each instance has a name. 

From the perspective of FMC NM, the FMC NS is partitioned into various (sub) NSs. Each (sub) NS is a collection of 
names of instances, whose classes are defined by the corresponding technology-domain-specific-model. 

For illustration, suppose the following Figure 8 shows the (sub) NSs for names of instances whose classes are defined 
by, say 3GPP/SA5 [4] (the one on the left) and MEF [5] (the one on the right of the figure). 





Figure 8: Two (sub) name spaces 

This document does not specify the following, since they are specified already by specifications of various technology- 
domain-specific-models : 

- The method by which the names within a (sub) NS can be made unique; 

This document specifies the method by which names among all (sub) NSs of the FNIM can be made unique. 

The following procedural steps apply for operators involved: 

- Register itself with a domain name (e.g. "acme.com") with a domain name registrar that is accredited by the 

Internet Corporation for Assigned Names and Numbers (ICANN), the organization charged with overseeing 
the name and number systems of the Internet. 

- For each (sub) NS it manages, construct a naming-path using the two domain components (dc=acme, 

dc=com) from its registered domain name. 

- The name-path may contain just the two domain components from its registered domain name. It may 
also contain more domain components such as organization units, e.g. (dc=FixedNetwork, dc=acme, 
dc=com; dc=mobileNetwork, dc=acme, dc=com) or localities, e.g. (dc=montreal, dc=acme, dc=com; 
dc=Sorrento, dc=acme, dc=com). 

- Use name-path as the root of its (sub) NSs. 

The following Figure 9 illustrates the use of two name-paths, where one has three and the other has two domain 
components, as the name-paths for the two (sub) NSs. 
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Figure 9: Use of two name-patlis 
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Annex A (informative): 

Modelling methodology/approach not recommended 

This appendix is a graphical presenting of an alternate approach to FNIM. The TM Forum/3 GPP Joint Harmonization 
Project group agreed not to recommend this alternate approach. 

One key aspect of this methodology/approach is that it requires one repository for all model components. A 
consequence of this methodology/approach would be: TM Forum would be charged with the task to produce solution 
specifications for FMC NM standards. 




Figure 10: Alternative approach to FNIM - not recommended 
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Annex B (informative): 

3GPP TS network resource models 

This appendix lists the 3GPP TS related to mobile managed resource models. This list is expanding (e.g. number of 
classes to be modelled is increasing). 

The FNIM, described in this paper, does not require a repository to physically hold copies of such specifications (and 
those of other SDOs or standard organizations including expert group such as BBF's ATM NM models) for design and 
generation of FMC NM solutions. 

- TS 32.622 Telecommunication management; Configuration Management (CM); Generic network resources 

Integration Reference Point (IRP): Network Resource Model (NRM) 

- TS 32.762 Telecommunication management; Evolved Universal Terrestrial Radio Access Network (E- 

UTRAN) Network Resource Model (NRM) Integration Reference Point (IRP): Information Service (IS) 

- TS 32.642 Telecommunication management; Configuration Management (CM); UTRAN network resources 

Integration Reference Point (IRP); Network Resource Model (NRM) 

- TS 32.752 Telecommunication management; Evolved Packet Core (EPC) Network Resource Model (NRM) 

Integration Reference Point (IRP): Information Service (IS) 

- TS 32.652 Telecommunication management; Configuration Management (CM); GERAN network resources 

Integration Reference Point (IRP); Network Resource Model (NRM) 

- TS 32.782 Home enhanced Node B (HeNB) Subsystem; Network Resource Model (NRM); Integration 

Reference Point (IRP): Information Service (IS) 

- TS 32.776 Home Node B (HNB) Subsystem; Network Resource Model (NRM); Integration Reference Point 

(IRP): Information Service (IS) 

- TS 32.742 Telecommunication management; Configuration Management (CM); Signalling Transport 

Network (STN) interface Network Resource Model (NRM) Integration Reference Point (IRP); Information 
Service (IS) 

- TS 32.732 Telecommunication management; IP Multimedia Subsystem (IMS) Network Resource Model 

(NRM) Integration Reference Point (IRP); Information Service (IS) 

- TS 32.722 Telecommunication management; Configuration Management (CM); Repeater network resources 

Integration Reference Point (IRP); information Service (IS) 

- TS 32.712 Telecommunication management; Configuration Management (CM); Transport Network (TN) 

Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS) 

- TS 32.692 Telecommunication management; Inventory Management (IM) network resources Integration 

Reference Point (IRP); Network Resource Model (NRM) 

- TS 32.682 Telecommunication management; Inventory Management (IM) Integration Reference Point (IRP); 

Information Service (IS) 

- TS 32.672 Telecommunication management; Configuration Management (CM); State Management 

Integration Reference Point (IRP); Information Service (IS) 
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Annex C (informative): 

TM Forum defined network resource models 

Refer to the following for TM Forum defined network resource models (extracted from [7]). 



b5vTMFa073 


p-MTOSI Model for consideration 


t 
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Annex D (informative): 
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